Agentic RAG与高级检索#

1. RAG 演进三阶段#

2. Self-RAG 核心机制#

LLM 生成特殊 token 做自评判断：

1. [Retrieve] yes/no → 是否需要检索
2. [ISREL] → 检索结果是否与问题相关
3. [ISSUP] → 生成内容是否被检索结果支持

不需要检索的问题直接回答，需要检索的才走 RAG 流程。

3. Corrective RAG (CRAG) 三档置信度#

检索结果置信度评估
  ├── HIGH（置信度 > 0.8）→ 直接基于检索内容生成
  ├── AMBIGUOUS（0.5-0.8）→ Query Rewrite + 重新检索
  └── LOW（< 0.5）→ 降级到 Web Search 或拒绝回答

4. Graph RAG 工作流#

离线阶段： 文档 → 实体抽取 → 关系抽取 → 构建知识图谱

在线阶段： Query → 实体识别 → 子图检索 → 图上下文 + 文档上下文 → LLM 生成

• 优势：支持多跳推理（“A 公司 CEO 的母校在哪个城市？“需要两跳）
• 局限：图谱构建成本高，实体关系提取有误差
• 开源实现：微软 GraphRAG（按社区做层级摘要，分 global / local 查询；官方仓库已声明基本进入维护模式，不再加新功能）、LightRAG（图 + 向量双层检索，建索引和增量更新更轻，仍在活跃迭代）。选型前先看项目维护状态

5. Adaptive RAG#

对 query 做复杂度分类：

• 简单事实题 → 直接 LLM 回答（无需检索）
• 单跳查询 → 标准 RAG
• 多跳推理 → Agentic RAG + 迭代检索

Agentic RAG是传统RAG的重大升级，核心区别是让Agent主动决策检索策略而不是走固定流程。传统Naive RAG不管什么问题都走检索再生成，Advanced RAG加了重排和混合召回但流程仍然固定。Agentic RAG让Agent自己判断要不要检索、怎么检索、结果够不够好。具体有几个关键模式：Self-RAG让LLM生成特殊token自评，先判断是否需要检索，检索后判断结果是否相关，生成后判断内容是否被检索结果支持。Corrective RAG做三档置信度分流：高置信度直接生成，中等置信度做Query Rewrite重新检索，低置信度降级到Web Search或拒绝回答。Graph RAG通过构建知识图谱支持多跳推理，比如”A公司CEO的母校在哪个城市”需要两跳才能回答。选型上不是越高级越好，简单FAQ场景传统RAG更快更稳，只有复杂查询和多跳推理场景才需要Agentic RAG。工程上常见的折中是用类似CRAG的三档置信度评估，配合规则引擎决定检索策略，把LLM调用留给真正需要判断的灰区。

追问方向：

• Self-RAG 和 CRAG 什么时候用？能组合吗？ → Self-RAG 判断”要不要检索”（减少不必要的检索），CRAG 判断”检索结果够不够好”（低置信度重试/降级）。可以组合：先 Self-RAG 判断是否需要检索，检索后用 CRAG 评估质量
• GraphRAG 的知识图谱怎么维护和更新？实体关系提取不准怎么办？ → 增量更新：文档变更时重新提取变更部分的实体关系。提取不准用人工校验高频实体 + LLM 交叉验证。图谱维护成本高是 GraphRAG 最大的工程挑战
• 检索置信度阈值怎么调？调太高太低分别什么后果？ → 太高（>0.8）→ 大量拒答影响用户体验；太低（<0.3）→ 低质量检索结果导致幻觉（>0.8、<0.3 是通用经验范围）。具体阈值依赖 reranker 的分数分布，要在自己的评测集上按拒答率和错答率标定，换模型必须重新标定
• Agentic RAG 延迟增加怎么优化？ → 自评判断可以用规则或 reranker 打分替代 LLM 生成（规则判断几乎零延迟，reranker 单次打分也比一次 LLM 生成快得多），Query Rewrite 用小模型，不必要的检索直接跳过（Self-RAG 短路）

易错点：

• ❌ “Agentic RAG 一定比传统 RAG 好” → 简单 FAQ 场景传统 RAG 更快更稳，过度设计反而增加延迟和成本
• ❌ “GraphRAG 适合所有场景” → 只有明确实体关系且需要多跳推理的场景才值得构建图谱
• ❌ “Self-RAG 需要专门训练” → 可以用 Prompt 实现类似效果（让 LLM 先判断是否需要检索）

结合项目时可以讲： 三档阈值怎么定、灰区用什么方式仲裁（规则 / reranker / LLM）及各自的延迟，检索策略由规则还是 LLM 决定，以及用评测集验证了哪些指标。